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Cloudflare Magic Transit 
tutela le reti e ne 
migliora le performance 


Cloudflare Magic Transit fornisce protezione DDoS e 
accelerazione del traffico per reti on-premise, cloud o 
ibride. Con datacenter che coprono 200 città e oltre 

51 Tbps di capacità di mitigazione DDoS, Magic Transit 
è in grado di rilevare e mitigare gli attacchi vicino alla 
loro origine in meno di 3 secondi, il tutto con vantaggi 
prestazionali integrati. 


In questo documento presentiamo i risultati dei test 
Catcehpoint che abbiamo eseguito sulla nostra rete 
per quantificare l'impatto della latenza con Magic 
Transit. | loro risultati dimostrano che le prestazioni di 
rete (latenza e perdita di pacchetti) sono migliorate 
per il cliente quando il traffico veniva instradato su 
Cloudflare Magic Transit. In particolare, nei risultati 
abbiamo osservato che la latenza è diminuita di 3 ms 
e che la perdita di pacchetti è stata pressoché nulla. 
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In che modo Magic Transit protegge l'infrastruttura di 
rete senza degradarne le prestazioni? 


Prima di Magic Transit, esistevano due principali strategie per proteggere l'infrastruttura di rete 
dagli attacchi DDoS: dispositivi hardware anti-DDoS on-premise e soluzioni di scrubbing basate 
sul cloud. 


I dispositivi hardware on-premise svolgono un ottimo lavoro per la protezione dell'infrastruttura, 
ma solo fino a un certo punto. Queste apparecchiature dispongono di larghezza di banda limitata 
e possono venire sopraffatte in caso di attacchi di grandi dimensioni o condotti in simultanea. 
L'hardware richiede inoltre un importante investimento iniziale e necessita di ingenti risorse per la 
gestione e la manutenzione. 


| centri di scrubbing basati sul cloud sono nati per offrire un'alternativa più semplice: instradare il 
traffico in centri dove sia possibile filtrare il traffico di attacco. Questa soluzione ha risolto il problema 
economico e i fastidi associati alla manutenzione dei dispositivi on-premise. 


Ma, a sua volta, ha creato un nuovo problema: una latenza significativa. 


Poiché questi provider di servizi cloud dispongono di un insieme limitato e geograficamente 
eterogeneo di centri di scrubbing, il traffico potrebbe dover percorrere una distanza considerevole 
prima di raggiungere la sua destinazione finale. | provider cloud generalmente dispongono di 
pochi centri di scrubbing, e se l'utente, o i suoi utenti finali, non sono vicini a uno di essi, il loro 
traffico dovrà percorrere una distanza notevole, anche se la destinazione finale è nelle vicinanze. 
Questo è il cosiddetto "effetto trombone", e spesso genera ritardi evidenti e piuttosto percepibili. 
(Viene detto "effetto trombone" perché, se si illustra su una mappa il lungo percorso di andata e 
ritorno intrapreso dal traffico, la sua forma assomiglia a quella di un trombone). 
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l "centri di scrubbing" sono pochi, distanti e dedicati alla mitigazione degli attacchi DDoS. Ciò richiede che il traffico di rete si 
sposti su un datacenter alternativo per ogni elaborazione di L4-7 aggiuntiva, causando un ulteriore ritardo. 
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Si consideri lo scenario di cui sopra, dove è necessario elaborare il traffico sia sui Layer 3-4 che 
per i servizi Layer 7 (come WAF, gestione bot, ecc.). In questo caso, il traffico raggiunge prima un 
centro di scrubbing L3 distante per la mitigazione DDoS L3, per poi essere inviato per ogni 
ulteriore elaborazione L7 a un datacenter secondario, aggiungendo un passaggio di rete al traffico 
end-to-end e introducendo così una latenza inutile. La latenza è particolarmente pronunciata se 

il provider cloud dispone di un numero limitato di centri di scrubbing, e se la fonte del traffico di 
rete è molto lontana. 


Magic Transit introduce una soluzione migliore. Invece di centri di scrubbing dedicati, lasciamo 
che sia ogni datacenter della rete globale di Cloudflare a gestire lo scrubbing. Infatti, ciascun 
datacenter di Cloudflare esegue lo stack completo dei servizi Cloudflare. Ciò significa che il 
traffico deve solo andare solo al più vicino datacenter di Cloudflare; e con datacenter in più di 200 
città in oltre 100 Paesi, è probabile che si trovi a breve distanza. 
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Ciascun datacenter Cloudflare esegue l'intero stack dei servizi L3-7, di modo che il traffico di rete venga elaborato nella stessa 
posizione. 


Ciò significa nessun effetto trombone e latenza davvero minima. Le prestazioni di rete erano una 
delle nostre principali preoccupazioni nel progettare Magic Transit; volevamo essere sicuri che i 
nostri utenti non dovessero sacrificare le prestazioni per il bene della sicurezza. 
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Test Catchpoint 


Per verificarlo, abbiamo utilizzato Catchpoint per eseguire alcuni test e determinare gli effetti 
dell'utilizzo di Magic Transit sulle prestazioni complessive della rete. Attraverso una distribuzione 
globale di sonde, abbiamo eseguito ping test ICMP su un indirizzo IP con Magic Transit e un altro senza 
Magic Transit, entrambi ospitati sulla stessa infrastruttura di rete. Questo ci ha permesso di misurare 
contemporaneamente latenza, perdita di pacchetti e jitter e vedere la differenza nelle prestazioni. 
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Prestazioni (ms) di latenza (round trip del ping) con Magic Transit (in blu) e senza Magic Transit (in grigio) 
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Prestazioni del jitter (ms) con Magic Transit (in blu) e senza Magic Transit (in grigio) 
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Prestazioni di perdita di pacchetti (percentuale) con Magic Transit (in blu) e senza Magic Transit (in grigio) 


Nel test illustrato in precedenza, la linea blu rappresenta le prestazioni utilizzando Magic Transit, 
mentre la linea grigia rappresenta quelle senza Magic Transit. 
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Risultati dei test 


Prestazioni Con Magic Transit (in blu) Senza Magic Transit (in grigio) 
Latenza 28,96 ms 31,98 ms 

Jitter 15,61 ms 15,24 ms 

Perdita di pacchetti 0,52% 5,26% 


Conclusioni principali tratte dai test 


e La latenza si è ridotta di 3 ms con l'utilizzo di Magic Transit 
e Il jitter è aumentato di 0,36 ms con l'utilizzo di Magic Transit 


e La perdita di pacchetti è stata pari quasi a zero (0,52%) utilizzando Magic Transit rispetto al 5,26% di 
perdita di pacchetti senza Magic Transit 


Cosa significano questi risultati? 


Latenza: la latenza è il tempo che impiegano i pacchetti di dati per viaggiare da un punto ad un altro sulla 
rete. Nei nostri test abbiamo osservato una latenza inferiore sulla rete di Cloudflare. 


Cloudflare ottimizza costantemente i percorsi del traffico in risposta allo stato dei diversi percorsi di rete, per 
cui i percorsi in uscita intrapresi dai pacchetti da Cloudflare alla rete dei clienti sono spesso più efficienti di 
quelli che tali pacchetti percorrerebbero senza l'ottimizzazione di Cloudflare. 


Ciò garantisce che la latenza della rete non venga aumentata e in molti casi, come si vede nei risultati dei 
nostri test, sia addirittura diminuita. Questo aspetto è particolarmente importante per le applicazioni sensibili 
alla latenza (in tempo reale), come ad esempio il gaming online e il Voice over IP (VoIP). 


Jitter: il jitter di rete è la varianza del ritardo tra la consegna dei pacchetti su una rete. Mantenere il jitter 
basso è fondamentale soprattutto per le applicazioni quali il VoIP. Con Magic Transit, il jitter è aumentato di 
0,36 ms. Si tratta di un dato considerato trascurabile, anche per le applicazioni sensibili al fattore jitter. 


Perdita di pacchetti: la perdita di pacchetti si verifica quando uno o più pacchetti in una trasmissione di rete 
non riescono a raggiungere la destinazione. A seconda del protocollo, la perdita di pacchetti può comportare 
una maggiorazione di tempo per la ritrasmissione oppure il deterioramento della qualità. Nel caso di 
trasmissioni estremamente sensibili al fattore tempo, come le videoconferenze, una perdita di pacchetti 
inferiore all'1% è considerata accettabile*. Nei nostri test abbiamo osservato che la perdita di pacchetti è 
scesa quasi a zero sulla rete di Cloudflare (rispetto a oltre il 5% di perdita di pacchetti senza Magic Transit) 


In sintesi, gli effetti di Magic Transit su latenza, jitter e perdita di pacchetti non comprometteranno 
l'esperienza dell'utente, e in molti casi potranno persino migliorarla. In altre parole, i clienti Cloudflare non 
devono preoccuparsi di "compromessi" nelle prestazioni di rete quando utilizzano Magic Transit. 


In più, Cloudflare Magic Transit si integra con l'intero stack di prodotti Cloudflare per la sicurezza, le 
prestazioni e l'affidabilità per ottimizzare ulteriormente le prestazioni delle proprietà Internet. 


Per maggiori informazioni su Cloudflare Magic Transit, visita il sito www.cloudflare.com/magic-transit 
o contattaci all'indirizzo: sales@cloudflare.com 


*https://web.archive.org/web/20131010010244/http://sdu.ictp.it/pinger/pinger.html 


1888 99 FLARE | enterprise@cloudflare.com | www.cloudflare.com/it-it/ 


r N 


WHITEPAPER CLOUDFLARE' 


© 2020 Cloudflare Inc. Tutti i diritti riservati. Il logo Cloudflare è un marchio 
di Cloudflare. Tutti gli altri nomi di società e prodotti possono essere marchi 
delle società cui sono rispettivamente associati. 


1888 99 FLARE | enterprise@cloudflare.com | www.cloudflare.com/it-it/ REV:BDES-1258.2020DEC14 


